Universal Access To All Knowledge
Home Donate | Store | Blog | FAQ | Jobs | Volunteer Positions | Contact | Bios | Forums | Projects | Terms, Privacy, & Copyright
Search: Advanced Search
Anonymous User (login or join us)
Upload

Reply to this post | See parent post | Go Back
View Post [edit]

Poster: Administrator, Curator, or StaffJonathan Aizen Date: Jan 21, 2003 10:41pm
Forum: etree Subject: Re: What if we disable FTP? What we need is our own client

All this is reminding me of an idea I came up with recently.

I want to design a custom client that integrates with the Archive (searching, browsing, etc.) that downloads much like an FTP client (and might even access files via FTP), but sets up file sharing. If all goes well, I'll learn the rest of the skills I need this semester. Of course, this doesn't immediately resolve anything, but it's an idea for the horizon. That will allow the best of all worlds - queued downloads, complete file sharing, full information on peers, and so on.

Reply to this post
Reply [edit]

Poster: datgeek Date: Jan 21, 2003 10:47pm
Forum: etree Subject: Re: What if we disable FTP? What we need is our own client

ok I don't want to push any buttons but what about "borrowing" ideas from a very popular file sharing program that is associated with wiki.etree.org > that uses antelope type sharing, runs on java... starts with a F.... anyhoo, its just an idea...

Reply to this post
Reply [edit]

Poster: dan Date: Jan 21, 2003 11:00pm
Forum: etree Subject: Re: What if we disable FTP? What we need is our own client

I'm not sure that we want to disable ftp. Earlier, someone asked the question what percentage of http downloads are done using bandwith sharing tools. I wonder this also. I think that it might be better at this point, temporarily, until John learns enough to write us our own program, to remove HTTP downloads that aren't file sharing. HTTP downloads are just too easy, and if it was made obvious that the preferred method (and faster method) was the OCN or BT software, then new users might use it, while allowing FTP lovers to continue doing what they are for now. I don't see a reason why shows that are available BT or OCN should have regular HTTP downloads availabe. (if this is already happening, just laugh at me.)
-Dan

Reply to this post
Reply [edit]

Poster: opencontent Date: Jan 21, 2003 11:10pm
Forum: etree Subject: Re: What if we disable FTP? What we need is our own client

To be honest, we aren't seeing a very high hit count for people doing the OCN downloads. It could be because alot of people use FTP, or that people do a right-click "save as" on the HTTP files. In any case, I think the utilization could definately be improved many-fold.

Reply to this post
Reply [edit]

Poster: Administrator, Curator, or StaffJonathan Aizen Date: Jan 21, 2003 11:01pm
Forum: etree Subject: Re: What if we disable FTP? What we need is our own client

Furthurnet is an inspiration for the idea, just as is Kazaa. But this would be significantly different.

It wouldn't be entirely peer-to-peer and would integrate very tightly with the website.

It would only allows downloads/shares of things in the Archive.

It would work with all the Archive's media types.

It would include the ability to download individual files.

Also, I think it'd have to be designed in C++, for the sake of efficiency.

All this is just daydreaming, nowhere close to a reality.

Let's talk about some more ideas that will work now.

Reply to this post
Reply [edit]

Poster: opencontent Date: Jan 21, 2003 10:54pm
Forum: etree Subject: Re: What if we disable FTP? What we need is our own client

If you're interested, the Tornado client supports a local XML-RPC interface that allows it to be controlled via another application, even a UI written in Flash. The XML-RPC interface supports all of the standard download manager controls like pause, resume, etc.

Otherwise, the OCN protocols are pretty simple (http://open-content.net/specs/), so if you were working on a client for archive.org, it would probably be useful to other OCN sites as well.